Say where the upload size ceiling actually is - #189
Conversation
The comment I left in #187 was still wrong, just wrong in a new direction. It said the enforceable limit lived in the petnote_image_signed / petnote_video_signed upload presets. The owner checked the Cloudinary console: a preset has no max-file-size setting at all, across all six tabs. That absence is precisely why the parameter was silently ignored and the signature could never match. The real ceiling is the account plan. Cloudinary rejects anything over it regardless of what we send — on the free tier, 10 MB for images and 100 MB for video. The constants here were chosen to match it: the image number IS the plan limit, and the video number is deliberately stricter. So a server-side ceiling has existed all along. It is just enforced by the platform rather than by us, which is a different claim from either comment this file has carried. Written as a table of where a limit can and cannot be enforced — plan, preset, signature — so the next person can see at a glance that the signature is not an option, rather than reasoning their way back to the bug. Ends with the rule outright: the signature proves the request came from us, it cannot constrain the upload. Comment only; no behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 74434c4e5d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // So: do not add parameters to the signature to enforce anything. The | ||
| // signature proves the request came from us; it cannot constrain the upload. |
There was a problem hiding this comment.
When a future upload control uses a supported Cloudinary parameter, this instruction would incorrectly discourage signing it. A signature binds the recognized request parameters—this function already relies on that behavior to constrain folder and upload_preset—so only the unsupported max_file_size parameter cannot provide the desired limit. Revise the comment to distinguish that parameter from supported signable upload options.
Useful? React with 👍 / 👎.
The comment I left in #187 was still wrong — just wrong in a new direction. It said the enforceable limit lived in the
petnote_image_signed/petnote_video_signedupload presets.The owner checked the Cloudinary console: a preset has no max-file-size setting at all, across all six tabs. That absence is precisely why the parameter was silently ignored and the signature could never match.
Where the ceiling actually is
So a server-side ceiling has existed all along. It's enforced by the platform rather than by us, which is a different claim from either comment this file has carried. Our constants were chosen to match it: the image number is the plan limit, the video number is deliberately stricter (80 MB against the plan's 100 MB).
Why the comment gets this much space
A wrong comment in this exact spot caused a production outage. The first version promised a guarantee Cloudinary doesn't offer; someone implemented it, and every upload broke. My replacement pointed at a setting that turns out not to exist, which would have sent the next person hunting through a console for it.
It's now written as the table above — plan, preset, signature — so the options are visible at a glance rather than reasoned back to from a claim. And it ends with the rule stated outright: the signature proves the request came from us, it cannot constrain the upload. If a tighter limit is ever needed, it has to be enforced after the fact by inspecting and deleting the asset, not before.
Comment only, no behaviour change.
buildandlintclean.🤖 Generated with Claude Code